The 3rd Generation Partnership Project (3GPP) technical report numbered TR 23.799 and entitled “Study on Architecture for Next Generation System,” version 0.8.0, September 2016 (hereinafter referred to as TR 23.799), represents one approach to the design of a system architecture for next generation mobile networks, also referred to as 5th generation (5G) networks. As proposed in the above referenced documents, the network can be logically divided into a control plane (CP) that supports network control functionality and a user plane (UP) that supports data traffic being communicated between User Equipment (UE), servers, and network functions available on the network. In some embodiments, a management plane may also be defined. It should be understood that the different planes are logical constructs. In many instances, the nodes and functions within the network may use the same physical hardware and connections, though they are considered to be logically distinct.
Communications between connected devices, such as UE and servers, are managed by the CP. Unlike current communication networks, with fixed short-life PDU sessions established between end points, in next generation networks it is proposed to that PDU sessions may sustain for relatively longer periods during which time PDU session parameters may need to be changed
Therefore, there is a need for a method and apparatus serving mobile wireless communication devices in wireless communication networks such as proposed 5G networks, in which PDU sessions may be configured and/or updated to reflect current PDU session parameters such as application system location or UP selection.
Network function virtualization (NFV) is a network architecture concept that uses the technologies of IT virtualization to create entire classes of virtualized network functions into building blocks that may be connected to each other or to other entities, or may be chained together, to create communication services. NFV relies upon, but differs from, traditional server-virtualization techniques, such as those used in enterprise IT. A virtualized network function (VNF) may consist of one or more virtual machines (VMs) running different software and processes, on top of standard high-volume servers, switches and storage devices, or even cloud computing infrastructure, instead of having custom hardware appliances for each network function. In other embodiments, a VNF may be provided without use of a Virtual Machine through the use of other virtualization techniques including the use of containers. In further embodiments, a customized hardware appliance may be resident within the physical infrastructure used for different virtual networks, and may be presented to each virtual network as a virtual version of itself based on a partitioning of the resources of the appliance between networks. For example, a virtual session border controller could be instantiated upon existing resources to protect a network domain without the typical cost and complexity of obtaining and installing physical network protection units. Other examples of VNFs include virtualized load balancers, firewalls, intrusion detection devices and WAN accelerators.
The NFV framework consists of three main components:    Virtualized network functions (VNFs) are software implementations of network functions that can be deployed on a network functions virtualization infrastructure (NFVI).    Network functions virtualization infrastructure (NFVI) is the totality of all hardware and software components that provide the resources upon which VNFs are deployed. The NFV infrastructure can span several locations. The network providing connectivity between these locations is considered as part of the NFV infrastructure.    Network functions virtualization MANagement and Orchestration (MANO) architectural framework (NFV-MANO Architectural Framework, for example the NFV-MANO defined by the European Telecommunications Standards Institute (ETSI), referred to as ETSI_MANO or ETSI NFV-MANO) is the collection of all functional blocks, data repositories used by these blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and orchestrating NFVI and VNFs.
The building block for both the NFVI and the NFV-MANO are the resources of an NFV platform. These resources may consist of virtual and physical processing and storage resources, virtualization software and may also include connectivity resources such as communication links between the data centers or nodes providing the physical processing and storage resources. In its NFV-MANO role the NFV platform consists of VNF and NFVI managers and virtualization software operating on a hardware platform. The NFV platform can be used to implement carrier-grade features used to manage and monitor the platform components, recover from failures and provide appropriate security—all required for the public carrier network.
Software-Defined Topology (SDT) is a networking technique that defines a logical network topology in a virtual network. Based on requirements of the service provided on the virtual network, and the underlying resources available, virtual functions and the logical links connecting the functions can be defined by an SDT controller, and this topology can then by instantiated for a given network service instance. For example, for a cloud based database service, an SDT may comprise logical links between a client and one or more instances of a database service. As the name implies, an SDT will typically be generated by an SDT controller which may itself be a virtualized entity in a different network or network slice. Logical topology determination is done by the SDT controller which generates a Network Service Infrastructure (NSI) descriptor (NSLD) as the output. It may use an existing template of an NSI and add parameter values to it to create the NSLD, or it may create a new template and define the composition of the NSI.
Software Defined Protocol (SDP) is a logical End-to End (E2E) technique that may be used within a network service instance. SDP allows for the generation of a customized protocol stack (which may be created using a set of available functional building blocks) that can be provided to different nodes or functions within the network, or network slice. The definition of a slice specific protocol may result in different nodes or functions within a network slice having defined procedures to carry out upon receipt of a type of packet. As the name implies, an SDP will typically be generated by one or more SDP controllers which may be virtualized functions instantiated upon a server.
Software-Defined Resource Allocation (SDRA) refers to the process of allocation of network resources for logical connections in the logical topology associated with a given service instance or network slice. In an environment in which the physical resources of a network are used to support a plurality of network slices, an SDRA controller will allocate the processing, storage and connectivity resources of the network to the different network slices to best accommodate the agreed upon service requirements for each of the network slices. This may result in a fixed allocation of resources, or it may result in an allocation that is dynamically changed to accommodate the different temporal distribution of traffic and processing requirements. As the name implies, an SDRA Controller will typically determine an allocation of resources, and may be implemented as a function that is instantiated upon a server.
Service Oriented Network Auto Creation (SONAC) is a technology that makes use of software-defined topology (SDT), software defined protocol (SDP), and software-defined resource allocation (SDRA) techniques to create a network or virtual network for a given network service instance. By coordinating the SDT, SDP, SDRA and in some embodiments Software Defined Network (SDN) control, optimization and further efficiencies can be obtained. In some cases, a SONAC controller may be used to create a network slice within which a 3rd Generation Partnership Project (3GPP) compliant network can be created using a virtualized infra-structure (e.g. VNFs and logical links) to provide a Virtual Network (VN) service. Those skilled in the art will appreciate that the resources allocated to the different VNFs and logical links may be controlled by the SDRA-type functionality of a SONAC controller, while the manner in which the VNFs are connected can be determined by the SDT-type functionality of the SONAC controller. The manner in which the VNFs process data packets may be defined by the SDP-type functionality of the SONAC controller. A SONAC controller may be used to optimize the Network Management, and so may also be considered to be a Network Management (NM) optimizer.
As the implementation details and standards of NFV evolve, systems and methods for ensuring that service level agreements (SLAs) can be satisfied in a consistent and reliable manner are highly desirable.
Within this disclosure, abbreviations that are not specifically defined herein should be interpreted in accordance with 3rd Generation Partnership Project (3GPP) Technical Standards, such as, for example, Technical Standard TS 23.501 V0.3.1 (March 2017).
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.